iT邦幫忙

2026 iThome 鐵人賽

DAY 28
1
Claude AI

研究生自救指南:30 天用 Claude Code 打造我的論文工具箱系列 第 28 篇

Day 28|我砍掉的三個工具:想清楚為什麼失敗,比做出來更難

  • 分享至 

  • xImage
  •  

前面二十七天寫的都是留下來的東西。今天寫三個沒留下來的——做到一半、或做完發現不能用,就停掉了。砍掉的理由,跟留下來的工具一樣值得寫,因為每一個失敗都精確地標出了這套工具箱的邊界在哪裡。

失敗一:自動判斷該用哪種統計檢定
我想做什麼:把清理好的資料丟進去,告訴它我的研究問題,讓它建議該跑 t 檢定、變異數分析還是回歸——省掉每次都要重新想「這個情況該用什麼方法」的時間。

做到哪一步:寫了規格檔,列出資料類型、變項數量、分布假設這些判斷依據,讓它讀完資料的描述統計之後給建議。第一次跑,建議聽起來很專業,格式工整,列了三個選項還附上理由。

為什麼砍掉:我拿建議去問統計顧問,發現有一個選項其實不適用——它沒有把我的研究設計是重複測量這件事納入考慮,用了不該用的獨立樣本檢定。問題不在它給錯答案,是這個錯誤讀起來完全合理,而且錯了比資料清理的錯更難被發現。 Day 14 反向計分算錯,跑出來的分數會明顯異常;統計方法選錯,跑出來的 p 值、效果量看起來都很正常,只有真正懂研究設計的人才看得出問題出在方法選擇上,不是數字本身。

這正好對上 Day 19 留下的那個問題——「分析階段要不要也寫成腳本,判斷成分更高,這條線要畫在哪還沒決定」。現在有答案了:不寫。 統計方法的選擇牽涉到我對整個研究設計的理解,這件事沒有辦法外包,工具給的建議看起來越專業,我越容易不假思索地相信它,這比它給一個明顯錯誤的答案更危險。

換成什麼做法:我還是會讓它幫我查某個統計方法的假設條件、幫我把 SPSS 的報表轉成 APA 格式的表格(這是 Day 16 已經在做的事),但「該用哪個方法」這個決定,回去問指導老師跟統計顧問,不再問 AI。

失敗二:自動生成論文標題與投稿關鍵字
我想做什麼:投稿期刊要想標題、要選三到五個關鍵字,關鍵字最好能對應到資料庫的正式索引詞彙,這件事我覺得很適合交給工具——把摘要丟進去,請它生成幾個標題選項跟關鍵字建議。

做到哪一步:做出來了,跑得動,一次能生成五個標題、八個關鍵字,看起來很有效率。

為什麼砍掉:兩個原因。第一,生成出來的標題全部長得很像——「探討某某與某某之相關性研究」這種公式化的句型,換了五次都是同一個骨架,這正是 Day 21 講的 AI 腔調問題,換一個地方又出現一次。第二個原因更根本:關鍵字要對應到資料庫的正式索引詞彙(例如生醫文獻常用的標準主題詞表),它生成的關鍵字很多是常見用語,不是資料庫真正收錄的正式詞條,拿去投稿等於是我自己選的字,跟工具直接查詢資料庫索引庫比對過的字,根本是兩種東西——用了反而還要花時間逐一去資料庫核對每個關鍵字是不是正式收錄的詞彙,不如一開始就自己查資料庫。

這個失敗告訴我一件事:有些任務看起來是「生成」,其實核心是「查詢一個外部的權威來源」。 標題可以生成,因為好不好是我的品味判斷;關鍵字不該生成,因為對不對有客觀答案,答案在資料庫裡,不在語言模型的訓練資料裡。這跟 Day 10 引用查證是同一個道理——會不會存在,要去問真正的資料庫,不是問一個「聽起來很像」的答案。

換成什麼做法:標題還是讓它幫忙發想幾個方向,但我會明確要求「不要用同一種句型」,逼它給出真正不同的骨架;關鍵字改成直接查資料庫本身的索引詞彙表,AI 只負責幫我把候選詞彙的定義排版整理,不負責生成詞彙本身。

失敗三:自動把口試逐字稿變成會議紀要
我想做什麼:Day 23 做的委員意見對照表,需要先從逐字稿裡切出一條一條意見,這個切分的動作原本我想也交給 AI——丟整份逐字稿進去,請它自動抓出重點、生成一份結構化的會議紀要。

做到哪一步:跑出來一份看起來很完整的摘要,重點分點列出,每位委員說了什麼都整理得很清楚。

為什麼砍掉:拿摘要跟原始逐字稿對照,發現一個問題沒辦法用規則解決——逐字稿裡有些話是委員半開玩笑提出來的、順口一提的建議,有些話是很堅持、講了兩次要求一定要改的。文字轉錄之後,這兩種話讀起來語氣一樣平。 摘要把它們用同樣的份量呈現,我差點把一句委員隨口提的建議,當成非改不可的強制意見,認真處理了大半天,反而漏掉另一條真正被強調了兩次的意見,因為它在摘要裡跟其他句子看起來同樣輕重。

這跟 Day 22 講的「文字模擬不能取代真人練習」是同一件事的另一面:不是模型不夠聰明,是文字本身在轉錄的那一刻,就已經把語氣、停頓、重複強調這些訊號濾掉了,濾掉的東西沒有辦法靠更好的摘要技術補回來,因為輸入端就已經不完整。

換成什麼做法:逐字稿我自己重聽一次錄音,邊聽邊標記「這條委員講得很重」「這條像是隨口一提」,標記完的版本才進 Day 23 的流程。這一步比較花時間,但省不掉——這正是這系列想強調的:有些時間省不下來,不是工具不夠好,是這件事本來就需要人在場才能判斷。

三個失敗的共同點
回頭看這三個,砍掉的理由分別是「判斷成分太高,錯了比資料錯更難發現」「該查權威來源,卻拿去生成」「輸入端的訊號本來就不完整,摘要救不回來」。表面上是三種不同的問題,但都指向同一件事:我做的每一個決定,是先問「這個任務的本質是什麼」,再決定要不要交給 AI,而不是反過來——因為 AI 做得出來,就假設這個任務適合它做。

這三個失敗案例花的時間不算少,各自都做到能跑的程度才停下來。但如果沒有真的做到那一步、拿真實情況去對照,我不會發現「聽起來很專業」跟「真的可靠」中間的差距有多大。失敗的成本,換來的是這句話:看起來能做,不代表該讓它做。

明天
Day 29:給指導老師的一封信。AI 進實驗室之後,師生關係怎麼變——這是整個系列裡我最不確定該怎麼寫的一篇。


上一篇
Day 27|研究資料到底能不能餵給 AI:把 Day 1 那條線的理由講清楚
下一篇
Day 29|給指導老師的一封信:AI 進實驗室之後,我們的關係怎麼變
系列文
研究生自救指南:30 天用 Claude Code 打造我的論文工具箱 共 30 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言